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Abstract. We develop a framework for computing two foundational 
analyses for concurrent higher-order programs: (control-)fiow analysis 
(CFA) and may-happen-in-parallel analysis (MHP). We pay special at- 
tention to the unique challenges posed by the unrestricted mixture of 
first-class continuations and dynamically spawned threads. To set the 
stage, we formulate a concrete model of concurrent higher-order pro- 
grams: the P(CEK*)S machine. We find that the systematic abstract in- 
terpretation of this machine is capable of computing both flow and MHP 
analyses. Yet, a closer examination finds that the precision for MHP 
is poor. As a remedy, we adapt a shape analytic technique — singleton 
abstraction — to dynamically spawned threads (as opposed to objects in 
the heap). We then show that if MHP analysis is not of interest, we 
can substantially accelerate the computation of flow analysis alone by 
collapsing thread interleavings with a second layer of abstraction. 



1 Higher-order is hard; concurrency makes it harder 

The next frontier in static reasoning for higher-order programs is concurrency. 
When unrestricted concurrency and higher-order computation meet, their chal- 
lenges to static reasoning reinforce and amplify one another. 

Consider the possibilities opened by a mixture of dynamically created threads 
and first-class continuations. Both pose obstacles to static analysis by them- 
selves, yet the challenge of reasoning about a continuation created in one thread 
and invoked in another is substantially more difficult than the sum of the indi- 
vidual challenges. 

We respond to the challenge by (1) constructing the P(CEK'^)S machine, 
a nondeterministic abstract machine that concretely and fully models higher- 
orderness and concurrency; and then (2) systematically deriving abstract inter- 
pretations of this machine to enable the sound and meaningful flow analysis of 
concurrent higher-order programs. 

Our first abstract interpretation creates a dual hierarchy of flow and may- 
happen-in-parallel (MHP) analyses parameterized by context-sensitivity and the 
granularity of an abstract partition among threads. The context-sensitivity knob 
tunes flow-precision as in Shivers's fc-CFA [21]. The partition among threads 
tunes the precision of MHP analysis, since it controls the mapping of concrete 



threads onto abstract threads. To improve the precision of MHP analysis, our sec- 
ond abstract interpretation introduces shape analytic concepts — chiefly, single- 
ton cardinality analysis — but it applies them to discover the "shape" of threads 
rather than the shape of objects in the heap. The final abstract interpretation 
accelerates the computation of flow analysis (at the cost of MHP analysis) by 
inflicting a second abstraction that soundly collapses all thread interleavings 
together. 

1.1 Challenges to reasoning about higher-order concurrency 

The combination of higher-order computation and concurrency introduces design 
patterns that challenge conventional static reasoning techniques. 

Challenge: Optimizing futures Futures are a popular means of enabling paral- 
lelism in functional programming. Expressions marked future are computed in 
parallel with their own continuation. When that value reaches a point of strict 
evaluation, the thread of the continuation joins with the thread of the future. 

Unfortunately, the standard implementation of futures 5 inflicts substantial 
costs on sequential performance: that implementation transforms (future e) 
into (spawn e), and all strict expressions into conditionals and thread-joins. 
That is, if the expression e' is in a strict evaluation position, then it becomes: 

(let ([$t e'] ) (if (thread? $t) (join $t) $t)) 

Incurring this check at all strict points is costly. A flow analysis that works for 
concurrent programs would flnd that most expressions can never evaluate to 
future value, and thus, need not incur such tests. 

Challenge: Thread cloning/replication The higher-order primitive call/cc cap- 
tures the current continuation and passes it as a first-class value to its argument. 
The primitive call/ cc is extremely powerful — a brief interaction between spawn 
and call/cc effortlessly expresses thread replication: 

(call/cc (lambda (cc) (spawn (cc #t)) #f)) 

This code captures the current continuation, spawns a new thread and replicates 
the spawning thread in the spawned thread by invoking that continuation. The 
two threads can be distinguished by the return value of call/cc: the replicant 
returns true and the original returns false. 

Challenge: Thread metamorphosis Consider a web server in which continua- 
tions are used to suspend and restore computations during interactions with the 
client [IB]. Threads "morph" from one kind of thread (an interaction thread 
or a worker thread) to another by invoking continuations. The begin-worker 
continuation metamorphizes the calling thread into a worker thread: 



(define become-worker 
(let ( [cc (call/cc (Isunbda (cc) (cc cc)))]) 
(cond 

[(continuation? cc) cc] 

[else (handle-next-request) 

(become-worker #t)]))) 

The procedure handle-next-request checks whether the request is the resump- 
tion of an old session, and if so, invokes the continuation of that old session: 

(define (handle-next-request) 
(define request (next-request)) 
(atomic-hash-remove! (session-id request) 
(Icimbda (session-continuation) 

(define answer (request->answer request)) 
(session-continuation answer)) 
(Icunbda () (start -new-session request) )) ) 

When a client-handling thread needs data from the client, it calls read-f rom-client, 
it associates the current continuation to the active session, piggy-backs a request 
to the client on an outstanding reply and the metamorphizes into a worker thread 
to handle other incoming clients: 

(define (read-f rom-client session) 
(call/cc (Icunbda (cc) 
(atomic-hash-set! sessions (session-id session) cc) 
(reply-to session)) 
(become-worker #t))) 

2 P(CEK*)S: An abstract machine model of concurrent, 
higher-order computation 

In this section, we define a P(CEK*)S machine — a CESK machine with a pointer 
refinement that allows concurrent threads of execution. It is directly inspired by 
the sequential abstract machines in Van Horn and Might's recent work [25] . 
Abstract interpretations of this machine perform both flow and MHP analysis 
for concurrent, higher-order programs. 

The language modeled in this machine (Figure [T]) is A- Normal Form lambda 
calculus [H] augmented with a core set of primitives for multithreaded program- 
ming. For concurrency, it features an atomic compare- and- swap operation, a 
spawn form to create a thread from an expression and a join operation to wait 
for another thread to complete. For higher-order computation, it features clo- 
sures and first-class continuations. A closure is a first-class procedure constructed 
by pairing a lambda term with an environment that fixes the meaning of its free 
variables. A continuation reifies the sequential control-flow for the remainder of 
the thread as a value; when a continuation is "invoked," it restores that control- 
flow. Continuations may be invoked an arbitrary number of times, and at any 
time since their moment of creation. 
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Fig. 1. ANF lambdarcalculus augmented with a core set of primitives for concurrency 
2.1 P(CEK*)S: A concrete state-space 

A concrete state of execution in the P(CEK*)S machine contains a set of threads 
plus a shared store. Each thread is a context combined with a thread id. A 
context contains the current expression, the current environment, an address 
pointing to the current continuation, and a thread history: 

<; E E ^ Threads x Store 
T e Threads = V {Context x TID) 
c e Context = Exp x Env x Addr x Hist 
p G Env — Var ^ Addr 
K G Kant = Var x Exp x Env x Addr + {halt} 
h G Hist contains records of thread history 
a G Store = Addr D 
de D = Value 
val e Value = Clo + Bool + Num + Kont + TID + Addr 
clo e Clo = Lam X Env 
a G Addr is an infinite set of addresses 
t G TID is an infinite set of thread ids. 

The P(CEK*)S machine allocates continuations in the store; thus, to add first- 
class continuations, we have first-class addresses. Under abstraction, program 
history determines the context-sensitivity of an individual thread. To allow 
context-sensitivity to be set as external parameter, we'll leave program history 



opaque. (For example, to set up a fc-CFA-like analysis, the program history would 
be the sequence of calls made since the start of the program.) To parameterize 
the precision of MHP analysis, the thread ids are also opaque. 

2.2 P(CEK*)S: A factored transition relation 

Our goal is to factor the semantics of the P(CEK*)S machine, so that one can 
drop in a classical CESK machine to model sequential language features. The 
abstract interpretation maintains the same factoring, so that existing analyses 
of higher-order programs may be "plugged into" the framework for handling 
concurrency. The relation (=4>) models concurrent transition, and the relation 
{—>■) models sequential transition: 

(^) ^ (Context X Store) x (Context x Store) 

For instance, the concurrent transition relation invokes the sequential transition 
relation to handle if, set ! , cas, callcc or procedure call0 

(c,g) ^ (c\a') 

({(c,t)}WT,a)^({(c',t)}UT,a') 

Given a program e, the injection function I : Exp — >■ State creates the initial 
machine state: 

= ({((e, [],ahait,^o),^o)} , [flhait n- halt]), 

where to is the distinguished initial thread id, ho is a blank history and Ohait is 
the distinguished address of the halt continuation. The meaning of a program 
e is the (possibly infinite) set of states reachable from the initial state: 

{,:I(e) 

Sequential transition example: callcc There are ample resources dating to 
Felleisen and Friedman detailing the transition relation of a CESK machine. 
For a recent treatment that covers both concrete and abstract transition, see 
Van Horn and Might P^*. Most of the transitions are straightforward, but in the 
interest of more self-containment, we review the callcc transition: 

c 

(([(callcc as)j, p,aK.,h),a) {{e, p" ,ai^,h'),a'), where 

h' record (c, h) 
(I(A (v) e)lp')^£((s,p,a) 
a — alloc(v, h') 
p = p [v ^ a\ 
a' = a[a a^]. 

^ The transition for cas is "sequential" in the sense that its action is atomic. 



The atomic evaluation function E : AExp x Env x Store — ^ D maps an atomic 
expression to a value in the context of an environment and a store; for example: 



£{v,p,a) =a{p{v)) 
£{lam, p,a) = {lam,p). 



(The notation f[x i— y] is functional extension: the function identical to /, 
except that x now yields y instead of f{x).) 

2.3 A shift in perspective 

Before proceeding, it is worth shifting the formulation so as to ease the process 
of abstraction. For instance, the state-space is well-equipped to handle a finite 
abstraction over addresses, since we can promote the range of the store to sets of 
values. This allows multiple vahies to live at the same address once an address 
has been re-allocated. The state-space is less well-equipped to handle the ap- 
proximation on thread ids. When abstracting thread ids, we could keep a set of 
abstract threads paired with the store. But, it is natural to define the forthcom- 
ing concrete and abstract transitions when the set of threads becomes a map. 
Since every thread has a distinct thread id, we can model the set of threads in 
each state as a partial map from a thread id to a context: 



It is straightforward to update the concurrent transition relation when it calls 
out to the sequential transition relation: 



2.4 Concurrent transition in the P(CEK*)S machine 

We define the concurrent transitions separately from the sequential transitions. 
For instance, if a context is attempting to spawn a thread, the concurrent relation 
handles it by allocating a new thread id t', and binding it to the new context c": 



Threads = TID Context. 
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— newtid : Context x Threads TID allocates a fresh thread id for the newly 
spawned thread. 

— record : Context x Hist — )■ Hist is responsible for updating the history of 
execution with this context. 

— alloc : Var x Hist — Addr allocates a fresh address for the supplied variable. 

The abstract counterparts to these functions determine the degree of approxima- 
tion in the analysis, and consequently, the trade-off between speed and precision. 

When a thread halts, its thread id is treated as an address, and its return 
value is stored there: 

(T[th^ (Iasl,p,ahait,/^)],^) ^ {T,a[t^£{8e,p,a)]). 

This convention, of using thread ids as addresses, makes it easy to model 
thread joins, since they can check to see if that address has value waiting or not: 

a{£{x, p, a)) = d 

(T[tK^ (|(join a;)lp,a,,h)],a) ^ {T[t ^ {e, p' , a',, h%a'), 
^ .. ^ 



where k — cr(aK) 
{v,e,p,a'^) = K 

p' ^ p[v a"] 
h' — record(c, h) 
a" = alloc{v, h') 
a' = a[a" ^d]. 



3 A systematic abstract interpretation of P(CEK*)S 

Using the techniques outlined in our recent work on systematically constructing 
abstract interpretations from abstract machines [23] . we can directly convert 
the P(CEK*)S machine into an abstract interpretation of itself. In the concrete 
state-space, there are four points at which we must inflict abstraction: over basic 
values (like numbers), over histories, over addresses and over thread ids. 

The abstraction over histories determines the context-sensitivity of the anal- 
ysis on a per-thread basis. The abstraction over addresses determines poly- 
variance. The abstraction over thread ids maps concrete threads into abstract 
threads, which determines to what extent the analysis can distinguish dynami- 
cally created threads from one another; it directly impacts MHP analysis. 

The abstract state-space (Figure [5]) mirrors the concrete state-space in struc- 
ture. We assume the natural point-wise, element-wise and member-wise lifting 
of a partial order (C) over all of the sets within the state-space. Besides the 
restriction of histories, addresses and thread ids to finite sets, it is also worth 



q £ E — Threads x Store 
f G Threads = fw V{Cmtext) 
c e Context = Exp x Env x Addr x Hist 
p G Snu = Var ^ Addr 
k G Kont = Var x Exp x Env x ^dcirfr + {halt} 
h G ffist contains bounded, finite program histories 
o G 'store = ^ddr D 
deb = TiWhTe) 
val G Value = CTo + Bool + iVtm + Ifoni + TW + .4ddr 
c/o G C/o = Lam X iSriii 

a G Addr is a finite set of abstract addresses 
t G TID is a finite set of abstract thread ids 

Fig. 2. Abstract state-space for a systematic abstraction of the P(CEK*)S machine. 

pointing out that the range of both Threads and Store are power sets. This pro- 
motion occurs because, during the course of an analysis, re-allocating the same 
thread id or address is all but inevitable. To maintain soundness, the analysis 
must be able to store multiple thread contexts in the same abstract thread id, 
and multiple values at the same address in the store. 

The structural abstraction map a on the state-space (Figure[3]) utilizes a fam- 
ily of abstraction maps over the sets within the state-space. With the abstraction 
and the abstract state-space fixed, the abstract transition relation reduces to a 
matter of calculation j^. The relation {"^) describes the concurrent abstract 
transition, while the relation {-^) describes the sequential abstract transition: 

c i: X i: 

{—°) C [Context X Store) x [Context x Store) 
When the context in focus is sequential, the sequential relation takes over: 

(c,a)^(c',a') 



[T[i ^ {c} U C], a) (T U [i {£'}],&') 

There is a critical change over the concrete rule in this abstract rule: thanks 
to the join operation, the abstract context remains associated with the abstract 
thread id even after its transition has been considered. In the next section, we 
will examine the application of singleton abstraction to thread ids to allow the 
"strong update" of abstract threads ids across transition. (For programs whose 
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oiHist{h) is defined by context-sensitivity 
oiTiD{t) is defined by thread-sensitivity 
CiAddr{a) is defined by polyvariance. 

Fig. 3. A structural abstraction map. 



maximum number of threads is statically bounded by a known constant, this 
allows for precise MHP analysis.) 



3.1 Running the analysis 

Given a program e, the injection function I : Exp — >■ State creates the initial 
abstract machine state: 

i{e) = £o |(e, [], ahait, /io)}] , [Shalt '-^ {halt}]^ , 

where ho is a blank abstract history and Shalt is the distinguished abstract 
address of the halt continuation. The analysis of a program e is the finite set of 
states reachable from the initial state: 



TZ{e) = : X(e) ^] . 



3.2 A fixed point interpretation 

If one prefers a traditional, fixed-point abstract interpretation, we can imagine 
the intermediate state of the analysis itself as a set of currently reachable abstract 
machine states: 



A global transfer function f : E ^ E evolves this set: 

fii) = {±(e)} U -.^ei and ? ^ c'} . 
The solution of the analysis is the least fixed point: lfp(/). 

3.3 Termination 

The dependence structure of the abstract state-space is a directed acyclic graph 
starting from the set S at the root. Because all of the leaves of this graph {e.g., 
lambda terms, abstract numbers, abstract addresses) are finite for any given 
program, the state-space itself must also be finite. Conscqucintly, there are no 
infinitely ascending chains in the lattice S. By Kleene's fixed point theorem, 
there must exist a least natural n such that lfp(/) = /"(0). 

3.4 Concurrent abstract transitions 

Guided by the structural abstraction, we can convert the concrete concurrent 
transitions for the P(CEK*)S machine into concurrent abstract transitions. For 
instance, if an abstract context is attempting to spawn a thread, the concurrent 
relation handles it by allocating a new thread id i', and binding it to the new 
context c": 

c 

, " ^ 

(f [f ^ {([(spawn e)], p, a^, h)} U C], a) ^ (f U [t ^ {c'} , t' ^ {c"}],a'), 

where i' = newiid{c, f[i ^ C U {c}]) 
c" = (e,/5,ahait,^o) 

h' = recorded, h) 

a! = alloc{v' , h!) 
p" = p'[v' ^ a'] 

c' = {e',p",a'^,h') 

a' = &U[a' ^ {{'}], where: 

— newtid : Context x Threads — >■ TID allocates a thread id for the newly 
spawned thread. 

— record : Context x Hist Hist is responsible for updating the (bounded) 
history of execution with this context. 

— alloc : Var x Hist — > Addr allocates an address for the supplied variable. 

These functions determine the degree of approximation in the analysis, and 
consequently, the trade-off between speed and precision. 



When a thread halts, its abstract thread id is treated as an address, and its 
return value is stored there: 

f' = f U[fK^{(|«l, p, Shalt, /l)}] ^ 

— , where 

iT',a)'^{T',au[t^£{^,p,a)]) 

the atomic evaluation function £ : A Exp x Env x Store D maps an atomic 
expression to a value in the context of an environment and a store: 

£{v,p,a) = cr{p{v)) 
£{lam, p,a) = {{lam,p)}. 

It is worth asking whether it is sound in just this case to remove the context from 
the threads (making the subsequent threads T instead of T'). It is sound, but 
it seems to require a (slightly) more complicated staggered-state bisimulation 
to prove it: the concrete counterpart to this state may take several steps to 
eliminate all of its halting contexts. 

Thanks to the convention to use thread ids as addresses holding the return 
value of thread, it easy to model thread joins, since they can check to see if that 
address has a value waiting or not: 

d E £{ao, p, a) d = a{d) 

(f U [f ^ {(Kjoin £B)l,p,aft,/i)}],<j) (f U [f ^ {(e,p',a'^,/i'),c}],a'), 
^ V ' 

c 

where k G criaa) 
{v,e,p,d'f,) = k 

p' = p[v a"] 

h' = record{c, h) 
d" = alloc{v, h') 
a = aU [d" d\ . 

3.5 Soundness 

Compared to a standard proof of soundness for a small-step abstract interpreta- 
tion, the proof of soundness requires only slightly more attention in a concurrent 
setting. The key lemma in the inductive proof of simulation states that when a 
concrete state <r abstracts to an abstract state if the concrete state can tran- 
sition to then the abstract state <J must be able to transition to some other 
abstract state ^' such that abstracts to c': 



Theorem 1. If: 



a{<;) C <f and <r <r', 



then there must exist a state <f' such that: 

a{(;') C <f' and ^ <f'. 

Proof. The proof is follows the case-wise structure of proofs like those in Might 
and Shivers [14] . There is an additional preliminary step: first choose a thread id 
modified across transition, and then perform case-wise analysis on how it could 
have been modified. 

3.6 Extracting flow information 

The core question in fiow analysis is, "Can the value val fiow to the expression 
se?" To answer it, assume that ^ is the set of all reachable abstract states. We 
must check every state within this set, and every environment p within that 
state. If a is the store in that state, then val may flow to as if the value a{val) is 
represented in the set £{x, p, a). Formally, we can construct a fiows-to relation, 
FlowsTo C Value x AExpr, for a program e: 

FlowsTo{val, as) iff there exist (T,(t) G ^^(e) and t G dom(T) such that 

{e,p,k) £T{t) and {a{val)} \Z £[se, p, a). 

3.7 Extracting MHP information 

In MHP analysis, we are concerned with whether two expressions e' and e" 
may be evaluated concurrently with one another in program e. It is straightfor- 
ward to decide this using the set of reachable states computed by the abstract 
interpretation. If, in any reachable state, there exist two distinct contexts at 
the relevant expressions, then their evaluation may happen in parallel with one 
another. Formally, the MHP C Exp x Exp relation with respect to program e is: 

MHP{e', e") iff there exist (f , a) G n{e) and i' , i" G dom{f ) such that 

(e',.,_,.)Gf(f') and (e", _,_,.) G f(t"). 

4 MHP: Making strong transitions with singleton threads 

In the previous section, we constructed a systematic abstraction of the P(CEK*)S 
machine. While it serves as a sound and capable flow analysis, its precision as 
an MHP analysis is just above useless. Contexts associated with each abstract 
thread id grow monotonically during the course of the analysis. Eventually, it will 
seem as though every context may happen in parallel with every other context. 
By comparing the concrete and abstract semantics, the cause of the impreci- 
sion becomes clear: where the concrete semantics replaces the context at a given 
thread id, the abstract semantics joins. 

Unfortunately, we cannot simply discard the join. A given abstract thread id 
could be representing multiple concrete thread ids. Discarding a thread id would 
then discard possible inter leavings, and it could even introduce unsoundness. 



Yet, it is plainly the case that many programs have a boundable number 
of threads that are co-live. Thread creation is considered expensive, and thread 
pools created during program initialization are a popular mechanism for cir- 
cumventing the problem. To exploit this design pattern, we can make thread ids 
eligible for "strong update" across transition. In shape analysis, strong update 
refers to the ability to treat an abstract address as the representative of a single 
concrete address when assigning to that address. That is, by tracking the cardi- 
nality of the abstraction of each thread id, we can determine when it is sound 
to replace functional join with functional update on threads themselves. 

The necessary machinery is straightforward, adapted directly from the shape 
analysis literature |1I2I11I10I14I19) ; we attach to each state a cardinality counter 
jj, that tracks how many times an abstract thread id has been allocated (but not 
precisely beyond once): 

E S = Threads x Store x TCount 
ji G fCmmt = fib {0, 1, 00} . 

When the count of an abstract thread id is exactly one, we know for certain 
that there exists at most one concrete counterpart. Consequently, it is safe to 
perform a "strong transition." Consider the case where the context in focus for 
the concurrent transition is sequential; in the case where the count is exactly 
one, the abstract context gets replaced on transition: 

(c,a)^(c^aO Ki) = ^ 

{f[i ^ {c} w q, a, A) ^ {f[i ^ {c'} u q, a', a). 

It is straightforward to modify the existing concurrent transition rules to exploit 
information available in the cardinality counter. At the beginning of the analysis, 
all abstract thread ids have a count of zero. Upon spawning a thread, the analysis 
increments the result of the function newtid. When a thread whose abstract 
thread id has a count of one halts, its count is reset to zero. 

4.1 Strategies for abstract thread id allocation 

Just as the introduction of an allocation function for addresses provides the 
ability to tune polyvariance, the newtid function provides the ability to tune 
precision. The optimal strategy for allocating this scarce pool of abstract thread 
ids depends upon the design patterns in use. 

One could, for instance, allocate abstract thread ids according to calling 
context, e.g., the abstract thread id is the last k call sites. This strategy would 
work well for the implementation of futures, where futures from the same context 
are often not co-live with themselves. 

The context-based strategy, however, is not a reasonable strategy for a thread- 
pool design pattern. All of the spawns will occur at the same expression in the 
same loop, and therefore, in the same context. Consequently, there will be no 



discrimination between threads. If the number of threads in the pool is known 
a priori to be n, then the right strategy for this pattern is to create n abstract 
thread ids, and to allocate a new one for each iteration of the thread-pool- 
spawning loop. On the other hand, if the number of threads is set dynamically, 
no amount of abstract thread ids will be able to discriminate between possible 
interleavings effectively, in this case a reasonable choice for precision would be 
to have one abstract thread per thread pool. 

4.2 Advantages for MHP analysis 

With the cardinality counter, it is possible to test whether an expression may 
be evaluated in parallel with itself. If, for every state, every abstract thread id 
which maps to a context containing that expression has a count of one, and 
no other context contains that expression, then that expression must never be 
evaluated in parallel with itself. Otherwise, parallel evaluation is possible. 

5 Flow analysis of concurrent higher-order programs 

If the concern is a sound flow analysis, but not MHP analysis, then we can per- 
form an abstract interpretation of our abstract interpretation that efficiently col- 
lapses all possible interleavings and paths, even as it retains limited (reachability- 
based) flow-sensitivity. This second abstraction map a' : S ^ I] operates on 
the system-space of the fixed-point interpretation: 

«'(l) = U^"- 

■fe€ 

The new transfer function, f' : S ^ S, monotonically accumulates all of the 
visited states into a single state: 

5.1 Complexity 

This second abstraction simplifies the calculation of an upper bound on compu- 
tational complexity. The structure of the set i7 is a pair of maps into sets: 

E = [tW ViContext)^ x (^Addr V{VaIue)J . 

Each of these maps is, in effect, a table of bit vectors: the first with abstract 
thread ids on one axis and contexts on the other; and the second with abstract 
addresses on one axis and values on the other. The analysis monotonically flips 
bits on each pass. Thus, the maximum number of passes — the tallest ascending 
chain in the lattice E — is: 



TID\ X \ Context\ + \Mdr\ x \ Vakie\. 



Thus, the complexity of the analysis is determined by context-sensitivity, as 
with classical sequential flow analysis. For a standard monovariant analysis, the 
complexity is polynomial fl7J. For a context-sensitive analysis with shared en- 
vironments, the complexity is exponential [22\ . For a context-sensitive analysis 
with flat environments, the complexity is again polynomial [15] . 

6 Related work 

This work traces its ancestry to Cousot and Cousot's work on abstract interpre- 
tation |3|4j . We could easily extend the fixed-point formulation with the implicit 
concretization function to arrive at an instance of traditional abstract interpre- 
tation. It is also a direct descendant of the line of work investigating control-flow 
in higher-programs that began with Jones [T^ and Shivers |20I21| . 

The literature on static analysis of concurrency and higher-orderness is not 
empty, but it is spare. Much of it focuses on the special case of the analysis of 
futures. The work most notable and related to our own is that of Navabi and 
Jagannathan pTB^. It takes Flanagan and Felleisen's notion of safe futures [718] . 
and develops a dynamic and static analysis that can prevent a continuation 
from modifying a resource that one of its concurrent futures may modify. What 
makes this work most related to our own is that it is sound even in the presence 
of exceptions, which are, in essence, an upward-restricted form of continuations. 
Their work and our own own interact synergistically, since their safety analysis 
focuses on removing the parallel inefficiencies of safe futures; our flow analysis 
can remove the sequential inefficiencies of futures through the elimination of run- 
time type-checks. Yahav's work is the earliest to apply shape-analytic techniques 
to the analysis of concurrency J24^. 

It has taken substantial effort to bring the static analysis of higher-order 
programs to heel; to recite a few of the major challenges: 

1. First-class functions from dynamically created closures over lambda terms 
create recursive dependencies between control- and data-fiow; k-CFA co- 
analyzes control and data to factor and order these dependencies |21) . 

2. Environment-bearing closures over lambda terms impart fundamental in- 
tractabilities unto context-sensitive analysis |22) — intractabilities that were 
only recently side-stepped via flattened abstract environments [15] . 

3. The functional emphasis on recursion over iteration made achieving high 
precision difficult (or hopeless) without abstract garbage collection to recycle 
tail-call-bound parameters and continuations |14) . 

4. When closures keep multiple bindings to the same variable live, precise rea- 
soning about side effects to these bindings requires the adaptation of shape- 
analytic techniques [11113] . 

5. Precise reasoning about flrst-class continuations (and kin such as exceptions) 
required a harmful conversion to continuation-passing style until the advent 
of small-step abstraction interpretations for the pointer-refined CESK ma- 
chine |23j . 



We see this work as another milestone on the path to robust static analysis of 
full-featured higher-order programs. 

7 Limitations and future work 

Since the shape of the store and the values within were not the primary focus 
of this work, it utilized a bhmt abstraction. A compelling next step of this 
work would generalize the abstraction of the store relationally, so as to capture 
relations between the values at specific addresses. The key challenge in such an 
extension is the need to handle relations between abstract addresses which may 
represent multiple concrete addresses. Relations which universally quantify over 
the concrete constituents of an abstract address are a promising approach. 
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